…0.2026081401

Builds on #145's v1.4.0 migration. Fixes further upstream breaking changes:
- aiecc flipped its Peano/Chess default; --no-xchesscc/--no-xbridge no longer
  exist, so drop them (Peano is now the implicit default)
- XRTTensor's residency tracking was reworked into a Storage/coherence-map
  model; XRTSubBuffer now shares its parent's _storage instead of
  bootstrapping incompatible state
- drop --dynamic-objFifos everywhere it was passed (default upstream now)

Also fixes iron/operators/__init__.py unconditionally importing the
stream-dse-backed operator, which broke its documented self-skip behavior
when onnx/stream-dse aren't installed.

Verified: 146/146 fast + 2830/2830 extensive operator tests pass on NPU2
hardware (some extensive failures under -n auto were pre-existing xdist
build-directory races, confirmed passing when rerun serially).

Co-Authored-By: Claude <noreply@anthropic.com>

mlir-aie's nightly (1.4.2.dev12) added a first-class subview() API backed by
a shared storage/coherence map between a view and its parent. This directly
supersedes XRTSubBuffer, which existed only because that capability didn't
exist upstream (per its own TODO). Deleting it also fixes a real bug it had:
XRTSubBuffer.to() always resynced the *entire* parent buffer, which could
clobber a sibling sub-view whose fresh device data hadn't been read back yet.
subview()'s shared coherence map tracks dirtiness per byte range instead, so
each view's .to() only moves what it needs to.

Converts all six call sites (iron/common/sequence.py, and four in
llama_npu.py) from XRTSubBuffer(...)/XRTSubBuffer.from_parent(...) to
parent.subview(offset_bytes, shape, dtype), then deletes the class.

Verified: 146/146 fast + 2830/2830 extensive operator tests pass on NPU2
hardware. llama_npu.py's call sites are syntax/import-checked only; no model
weights available locally to run it end-to-end.

Co-Authored-By: Claude <noreply@anthropic.com>

…_arch()

get_kernel_dir() reimplemented the device-arch-to-kernel-dir-string mapping
that mlir-aie's aie.utils.compile.utils.resolve_target_arch() now provides.
Keep our own no-arg auto-detect default (resolve_target_arch(None) returns
"aie2" unconditionally rather than checking the current device, which would
silently regress every no-arg call site on NPU2 hardware), but delegate the
actual device->arch-string logic once a concrete device is known.

Verified: 2830/2830 operator tests pass on NPU2 hardware.

Co-Authored-By: Claude <noreply@anthropic.com>

Replaces the hand-built clang++/xchesscc invocation in
KernelCompilationRule.compile() with aie.utils.compile.utils's
compile_cxx_core_function(), wrapped in PythonCallbackCompilationCommand
(which exists precisely for this: an arbitrary Python callable deferred
into the same plan/execute contract as ShellCompilationCommand).

This looked architecturally blocked at first (IRON's compile() methods
return commands for a separate execute() step, while upstream's function
runs synchronously), but IRON's execute() is already fully sequential in
Python -- the only real parallelism is aiecc's own internal -j flag inside
a single invocation, which is unaffected here since this rule only compiles
individual kernel objects, not the aiecc/xclbin step. Nothing is lost by
switching to a blocking call under a deferred wrapper.

peano_dir/mlir_aie_dir were already always sourced from
aie.utils.config.peano_install_dir()/root_path() (iron/common/context.py),
the same config module the upstream function reads internally, so there's
no override capability to lose. xchesscc_wrapper resolves via `shutil.which`
upstream instead of an absolute path IRON constructed itself, but the wheel
install puts it on PATH (ironenv/bin/xchesscc_wrapper), so this is a
non-issue in the standard install.

-Wno-missing-template-arg-list-after-template-kw is kept as an IRON-side
extra flag (Peano-only, matching prior behavior) since it's specific to our
kernel sources and upstream's default flag list doesn't include it.

Symbol renaming/prefixing for operator fusion (_rename_symbols/
_prefix_symbols) stays IRON-side; upstream has no equivalent multi-symbol
bulk-prefix operation.

Verified: 146/146 fast + 2830/2830 extensive operator tests pass on NPU2
hardware, including a from-scratch rebuild (rm -rf build/) to exercise every
kernel compile through the new path. The use_chess=True path is unexercised
by any test (also true before this change).

Co-Authored-By: Claude <noreply@anthropic.com>

Replaces the hand-built aiecc invocation in AieccXclbinInstsCompilationRule
and AieccFullElfCompilationRule with aie.utils.compile.utils's
compile_mlir_module(), wrapped in PythonCallbackCompilationCommand (same
pattern as the prior KernelCompilationRule change).

Two real gaps had to be worked around, not just papered over:

- compile_mlir_module() always names its own copy of the MLIR source
  "aie.mlir" inside a work_dir it controls, rather than accepting an existing
  file path. IRON's build previously kept every artifact's .mlir file (and
  aiecc's ".prj" companion) at a distinctive flat filename in one shared
  build/ directory. Introduced _aiecc_work_dir(), giving each MLIR source its
  own "<name>.mlir.d/" subdirectory, and updated the one place that depended
  on the old "<name>.mlir.prj" convention (OperatorSequence's params.txt
  lookup in sequence.py) to derive the new path the same way.

- aiecc resolves an MLIR module's relative kernel-object references (e.g.
  link_with = "axpy.o") against that work_dir, not against the flat build_dir
  where KernelCompilationRule/ArchiveCompilationRule actually produced them.
  Added _link_build_outputs_into() to symlink the build directory's existing
  outputs into each artifact's work_dir before compiling, rather than
  reworking where kernel objects get built.

Known, accepted regression: compile_mlir_module() resolves aiecc via
aie.utils.compile.utils's own config.aiecc_path(), which does not honor the
AIECC_PATH env var IRON previously supported for pointing a build at a
locally-built aiecc without reinstalling the wheel. No test exercises this,
but it's a real dev-workflow feature being dropped, not just an implementation
detail.

peano_dir/mlir_aie_dir/build_dir are no longer threaded into
AieccCompilationRule's constructor (dead after this change), simplifying the
context.py call sites accordingly.

Verified: 146/146 fast + 2830/2830 extensive operator tests pass on NPU2
hardware, from a clean build/ (rm -rf) to exercise every aiecc invocation
through the new path, and again from a warm cache.

Co-Authored-By: Claude <noreply@anthropic.com>

Bumps to the latest nightly wheels as of 2026-08-20 (mlir-aie
1.4.2.dev16+g7e00b57, llvm-aie 22.0.0.2026082001+84660bc3), up from
1.4.2.dev12 / 2026081401.

Verified: 725/750 fast (non-extensive) operator/infra tests pass on
NPU2 hardware. The 25 failures are the pre-existing fused-dispatch
aiebu-asm gap (XRT 2.20.0 lacks aiebu-asm on PATH; needs >=2.21),
unrelated to this bump.

Co-Authored-By: Claude <noreply@anthropic.com>

SequenceFullELFCallable.params looked for params.txt under a nested
"aie.mlir.prj" subdirectory of the aiecc work dir. That convention matched
aiecc's *default* project-dir naming (used when --tmpdir is omitted), but
compile_mlir_module() (introduced in 4f50d26) always passes --tmpdir
explicitly, in which case aiecc treats that directory as the project dir
itself rather than nesting another ".prj" folder under it. Confirmed against
a fresh build/<name>.mlir.d/ directory: aie.mlir, bif_main.bif, cdo_main/ all
land directly in it, not in a nested aie.mlir.prj/.

This is the only caller of ParameterScratchpad in the tree, and only
exercised by the llama_3.2_1b decode path (cache_offset/softmax_vector_size),
so it wasn't caught by the 146/146 fast + 2830/2830 extensive operator runs.

Co-Authored-By: Claude <noreply@anthropic.com>

3cded00 replaced IRON's hand-rolled XRTSubBuffer with upstream
NpuTensor.subview() for the XRT dispatch path (SequenceXclbinCallable), but
left one spot behind: SequenceReferenceCallable's pure-CPU path still built
its sliced sub-buffers by hand, constructing a bare CPUOnlyTensor and
overwriting its _data/_shape fields directly with a numpy slice.

CPUOnlyTensor is itself an NpuTensor subclass and already implements
_subview(), so this was reimplementing, by hand, what parent.subview(...)
already does for this backend -- minus the 64-byte coherence-granule
alignment check subview() enforces "for every backend, including the
CPU-only one that has no coherence concern of its own... so a layout
validated against the test backend stays valid on a device" (per its
docstring). That check previously only fired on the XRT path; a layout
that would fail on hardware could silently pass under dispatch="reference".

Once both _make_subbuffer overrides just called .subview() with the same
arguments, the hook itself stopped pulling weight: inlined the .subview()
call directly into the shared _PerBufferCallable._resolve_buffer and
deleted _make_subbuffer from both subclasses and the base class. Only
_make_buffer (XRTTensor vs. CPUOnlyTensor construction) remains as the
per-backend hook, which is genuine backend variation.

fuse_mlir() (iron/common/compilation/sequence.py) is out of scope here: it
generates memref.subview/reinterpret_cast MLIR directly to implement IRON's
own operator-fusion runlist calling convention, which has no upstream
equivalent to delegate to.

dispatch="reference" had no test coverage at all in
iron/tests/infrastructure/sequence.py before this change, and specifically
none exercising slice_info/explicit_buffer_sizes resolution on the CPU
backend -- the only real caller of sliced buffers (llama's per-head
attention slicing) only runs the XRT path. Added
test_reference_dispatch_resolves_sliced_buffer to close that gap.

Verified: 755/755 fast (non-extensive) operator/infra/application tests
pass on NPU2 hardware (24 llama tests skip, pre-existing XRT 2.20.0 gap),
including the new test and the full iron/tests/infrastructure/sequence.py
suite (80/80). Extensive suite not re-run: its markers cover per-operator
kernel parameter sweeps, orthogonal to this sequence-dispatch change.

Co-Authored-By: Claude <noreply@anthropic.com>